Skip to content

Conversation

@tidoust
Copy link
Member

@tidoust tidoust commented Jul 25, 2025

Via #1903 (comment).

This adds a new extended key to entries in the consolidated CSS that lists URLs of specs that extend the base definition. For properties, the URLs target the actual extended definition. For functions and types, the URLs merely target the spec without any specific fragment, because there is no actual definition and we don't know where the extension appears at the consolidation phase.

One question I wondered about is whether to use a separate extended key or to turn the href key into an array of references, with the first reference targeting the base definition. I stuck to a separate key on the grounds that most consumers that need a URL probably want a single URL to start with. Also, some of the constructs don't have any extension for now (at-rules, selectors, descriptors)... but then they might in the future. Having a single array might be a better approach?

Note this also prepares the consolidation to deal with extended functions and types (same update as that made in #1903). As opposed to extensions of properties where new values are added to the syntax, function/type extensions re-define the entire syntax. Reffy does not support extraction of function/type extensions in itself yet, so that part of the update is not going to be used for now.

This adds a new `extended` key to entries in the consolidated CSS that lists
URLs of specs that extend the base definition. For properties, the URLs target
the actual extended definition. For functions and types, the URLs merely target
the spec without any specific fragment, because there is no actual definition
and we don't know where the extension appears at the consolidation phase.

Note this also prepares the consolidation to deal with extended functions and
types. As opposed to extensions of properties where new values are added to the
syntax, function/type extensions re-define the entire syntax.

Reffy does not support extraction of function/type extensions in itself yet, so
that part of the update is not going to be used for now.
@tidoust tidoust requested a review from dontcallmedom July 25, 2025 13:33
Copy link
Member

@dontcallmedom dontcallmedom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you want to mark this as draft assuming this can't be merged the same way #1903 couldn't?

@tidoust
Copy link
Member Author

tidoust commented Jul 25, 2025

This one can be merged. And having the extended property is probably a good thing to have when we start releasing the consolidated json as an npm package.

The code that deals with extended functions/types simply won't have any extended functions/types to deal with. That shouldn't change anything and shouldn't break anything in particular.

@tidoust tidoust merged commit 5a0c620 into main Jul 25, 2025
1 check passed
@tidoust tidoust deleted the css-extensions branch July 25, 2025 13:56
tidoust added a commit that referenced this pull request Jul 28, 2025
Feature patched:
- [CSS consolidation] Add `extended` to store list of extension URLs (#1904)

Dependencies bumped:
- Bump rollup from 4.45.1 to 4.46.1 (#1906)
- Bump web-specs from 3.58.0 to 3.59.0 (#1907)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants